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NULL-MODEM CABLES 

Figure 1 shows two diagrams for null-mo- 
dem cables: one that appeared in PC Mag- 
azine's January 1 7, 1 989, Lab Notes col- 
umn, the other for a null-modem cable sold 
by a popular mail-order house. Why are 
they different? Shouldn't all null-modem ca- 
bles be similarly wired? And will both cables 
work with PC Magazine's ZCOPY utility, 
which also appeared in the January 17, 
1989, issue? 

William H. Dixon 

Leesburg, Florida 

j : j y Not all null-modem cables are cre- 
ated equal. The Electronics Indus- 
11111 tries Association (EIA) RS-232 
"lecification from which we derive our 
xndards for asynchronous serial commu- 
nications doesn't address the issue of direct 
PC-to-PC communications and therefore 
doesn't delineate what a null-modem cable 
should look like. As a result, you'll find 
several different variations on the "stan- 
dard" null-modem cable. Whether or not a 
given cable will work with a selected piece 
of software depends on how the RS-232 
control pins are used to control the flow of 
data. 

In its simplest form, a null-modem ca- 
ble is nothing more than a serial cable with 
pins 2 and 3 — the Transmit Data (TD) and 
Receive Data (RD) pins — crossed so that 
what is transmitted on pin 2 at one end will 
show up on pin 3 at the other, and vice 
versa. If no handshaking is performed at 
the hardware level, this arrangement is 
sufficient for rudimentary but effective 
data transfer between devices. 

What is hardware handshaking? By 
definition, hardware handshaking is per- 
formed when two programs manipulate 
RS-232 control pins— DTR, DSR, RTS, 
and CTS — to achieve a hardware-based 
form of flow control. For example, in 
^^R/DSR handshaking, the sender asserts 

A (Data Terminal Ready) before send- 
ing the first character in a stream of data 
and waits for DSR (Data Set Ready) to be 
asserted in return. RTS/CTS handshaking 
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works in a similar manner, but uses the Re- 
quest To Send and Clear To Send pins 
rather than Data Terminal Ready and Data 
Set Ready. In either case, the sender de- 
lays transmitting data until the receiver is 



ready. Many serial communications pro- 
grams use these or similar forms of hand- 
shaking to ensure that the PC on the trans- 
mitting end doesn't attempt to send data 
before the PC on the receiving end is pre- 
pared to accept it. 

An alternative to hardware handshak- 
ing is software flow control. Programs that 
use the popular XON/XOFF flow-control 
protocol, for example, send special XON 
and XOFF characters (binary codes 17 and 
19, respectively) to regulate the flow of 
data. If the receiver detects an impending 
buffer-full condition, for example, it trans- 
mits an XOFF character signaling the 
sender to suspend data transmission. 
When it's prepared to accept more data, it 
sends an XON character telling the sender 
to resume. Other alternatives are to forgo 



THE NULL-MODEM CABLE 




Key: TD = Tram 
CTS = Clear To 
DCD = Data Ca 



ransmit Data; RD = Receive Data; RTS = Request To Send: 
To Send; DSR = Data Set Ready; GND = Ground; 
Carrier Detect; DTR = Data Terminal Ready 



Figure 1 : Here are two variations of the "standard" null-modem cable. There is no recognized 
standard for wiring null-modem cables, because the EIA RS-232 specification does not concern itself 
with direct PC-to-PC communications issues. 
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COMPLETE LISTING 



1 



Figure 2: This DEBUG listing creates WHATNDP.COM, a short utility that reveals whether or not 
there's a math coprocessor installed in the PC it's run on, and if there is, whether it's an 8087, 287, or 
387. Be sure to include the blank line between RET and RCX near the end of the listing. 



N WHATNDP i 
A 

JMP 

DB 

DB 

0B 

DB 

DB 

DB 

DB 

FINIT 

FSTCW 

CMP 

JZ 

MOV 

MOV 

INT 

RET 

MOV 

MOV 

INT 

MOV 

AND 

WAIT 

FLDCW 

WAIT 

FDISI 

WAIT 

FSTCW 

TEST 

JN2 

MOV 

FINIT 

FLD1 

FLDZ 

FDIVP 

FLD 

FCHS 

FCOMPP 

FSTSW 

WAIT 

MOV 

SAHF 

JZ 

MOV 

MOV 

INT 

MOV 

MOV 

INT 

RET 

RCX 
9B 
W 




COM 
0136 

0d,0a,-no ndp installed-, 0D,0A,"$" 
zd,0a, -ndp is an 80$" 
■87$" 
■287$" 
"387$" 
0D,0A,"$" 
0,0 



[0134] 

BYTE PTR [0135], 3 

014B 

AH, 9 

DX.0102 

21 

AH, 9 

DX.0117 

21 

DX,0126 

WORD PTR [0134],FF7F 
[0134] 



[0134] 

WORD PTR [0134], 80 

018F 

DX,0129 



ST(1),ST 
ST(0) 



[0134] 

AX, [0134] 

018F 
DX,012D 
AH, 9 

21 

AH, 9 

DX,0131 

21 



Check for coprocessor 
by initializing it 
and looking at the 
bits 8 and 9 of the 
control word 

Exit if there's nothing 
there 

;Print opening message 



;Test for 8087 by seeing 
; if the FDISI instruction 
; Bets the I EM bit in the 
; coprocessor control word 



; Branch if NDP is an 8087 
distinguish between 287 
; and 387 by determining 
whether the NDP is 
initialized to affine 
(387) or projective 
(287) infinity 



; Branch if 2 87 
;It's a 3871 

; Print NDP type and exit 




flow control altogether, or to use a packet- 
based file-transfer protocol such as Kermit 
or Xmodem. 

The advantage to using a file-transfer 
protocol is that it's relatively easy to build- 
in error-checking logic, ensuring not only 
that the sending and receiving devices 
communicate with each other, but also that 
what comes across the line is free from ran- 
dom errors. 

A typical null-modem cable is wired to 
short-circuit a program's dependency on 
any RS-232 pins other than TD and RD. 
Both cables shown in Figure 1 , for exam- 
ple, work equally well with programs that 
employ DTR/DSR handshaking, 
RTS/CTS handshaking, or no handshak- 
ing at all. In addition, both cables tie an 
RS-232 output into DCD just in case the 
software running on the PC won't work 
unless Data Carrier Detect is asserted. The 
only difference is the physical wiring of 
DCD: the cable on the left loops the RTS 
output into DCD, while the one on the 
right loops DTR into DCD. 

Will these null-modem cables work 
with ZCOPY? Yes. ZCOPY uses a pack- 
et-based data-transfer protocol in lieu of 
handshaking. The transfer isn't unlike an 
Xmodem upload or download; the sender 
transmits a packet of data, complete with a 
CRC value and other control information, 
and the receiver either acknowledges the 
packet and its contents or asks the sender to 
retransmit the packet. As a result, ZCOPY 
will work with virtually any null-modem 
cable — the only requirement being that 
TD and RD appear on opposite pins on op- 
posite ends. 

IDENTIFYING MATH 
COPROCESSORS 

In a recent Tutor column, we developed a 
short program called WHATCPU, which 
identifies the type of CPU it's running on. 
This time we'll build WHATNDP, a pro- 
gram that identifies what type of Intel math 
coprocessor — if any — is present in the 
host PC. 

The best all-around set of routines I've 
seen for identifying Intel NDPs (Numeric 
Data Processors) came to us a couple of 
years ago, courtesy of reader Baron L. 
Roberts. WHATNDP incorporates a 
slightly modified version of his routines. 
Like WHATCPU, which relies on known 
differences between the various Intel 
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CPUs to identify CPU types, WHATNDP 
uses documented differences in the Intel 
NDP chips to distinguish between 8087s, 
80287s, and 80387s. 

The DEBUG listing for WHATNDP 
.COM is shown in Figure 2. The first test it 
applies is one that was presented in the 
March 13, 1990, Tutor column for deter- 
mining whether or not there's a math co- 
processor installed. An FNTNIT is execut- 
ed to initialize the coprocessor (if it's 
there) and the coprocessor control word is 
transferred to a memory location where it 
can be inspected. FNINJT sets bits 8 and 9 
of the control word on all Intel math chips. 



Thus, if bits 8 and 9 of the memory loca- 
tion that the control word was transferred 
to are set after the operation is complete 
(the memory location was originally set to 
0), WHATNDP concludes that there must 
be a coprocessor present. 

The next test separates 8087s from 287s 
and 387s. The key is that the coprocessor 
instructions FDISI and FENI, which dis- 
able and enable coprocessor interrupts by 
setting and clearing the EM (Interrupt En- 
able Mask) bit in the coprocessor com 
word, are ignored on the 287 and 387 but 
not on the 8087. WHATNDP manually 
clears the IEM bit, then executes an FDISI 




